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ABSTRACT 



A method for encoding network data, such as Internet 
Protocol (IP) data, into a format for transmission over a 
satellite system is described. The network data is configured 
in a packet having a data block and header information. The 
network data packet is encoded into a variable-length multi- 
packet transport (MPT) frame. The MPT frame comprises a 
data frame to hold data and header information. The IP 
packet in inserted its entirety into the data frame of the MPT 
frame. The variable-length MTP frame is then encoded into 
one or more fixed-length MTP packets. Each MPT packet 
has a data fragment block comprising a portion of the MTP 
frame and associated header information to designate what 
portion of the MTP frame is contained in the data fragment 
block. The MPT packets are sized to be embedded as a 
specific size payload of the satellite packet that is transmit- 
ted over a satellite network. Using this method, data 
received over a data network (i.e., Ethernet or Internet) in 
large network data packets are broken into smaller packets 
defined by the mult-packet transport. These smaller packets 
are then inserted as the data payload within standard fixed- 
size packets suitable for transmission across a particular 
distribution medium, such as satellite network. The network 
data remains independent of the underlying network and can 
be easily extracted at the receiver for use by computer 
applications. 

35 Claims, 7 Drawing Sheets 
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MULTI-PACKET TRANSPORT STRUCTURE type of packet directly to another type of packet is not 

AND METHOD FOR SENDING NETWORK particularly useful. The same problem persists for other 

DATA OVER SATELLITE NETWORK network data formats in addition to IP and other satellite 

formats in addition to DSS. 

RELATED APPLICATION 5 i t would be beneficial to provide a transport layer that 

Tnis application is based on Provisional Application No. « ab,es variable-length network data packets to be carried in 

60/018527, which was filed May 28, 1996, to which priority fixed-size satellite packet, as well as other types of network 

is claimed. P ackets - 

Another issue concerns use of the data after it is trans- 

TECHNICAL FIELD 10 mitted over the satellite network. Computer applications use 

m . . , , , . ' standard sets of Application Programming Interfaces (APIs) 

This invention relates to methods for sending computer {q transmit and receiye da(a Qver and QVer (he 

network data, and particularly Internet Protocol (IP) data, Imemet For e te applications designed to run on 

over a satellite network. This invention also relates to a Wiadows(g) . 5ased operating systems employ a standard set 

multi-packet transport structure that supports network data is of Apis that are defined - n , hc willdows Sockets 

in packet sizes suitable for transmission over the satellite s mcation? a well lasom specification. TTiese APIs have 

network, as well as other types of networks. beeQ dcfined by committecs and are in use _ 

BACKGROUND OF THE INVENTION 11:10 Sockets P r ° vide a network independent way to 

send and receive data, no matter what the underlying corn- 
Conventional satellite systems transmit data in standard 20 puter network (e.g., Ethernet, asynchronous transfer mode 
size digital packets. As an example, one satellite network, (ATM), etc.). Computer applications do not need to be 
referred to as the "digital satellite system" or "DSS" specially written to receive data from a particular network, 
network, transmits data in 147-byte packets. Instead, a developer writes code for an application that 
FIG. 1 shows a conventional DSS data packet 20. It has interfaces to the Windows® Sockets API, enabling the 
a three-byte header 22, a 127-byte payload 24, and a 17-byte 25 application to send and receive data over a number of 
trailer 26. The header 22 contains four flag bits, twelve different networks supported by the computer's hardware, 
addressing bits for the service channel identification number It would be beneficial to devise a technique to repackage 
(SCID), four sequence bits, and four type bits. The payload a network data packet, such as an IP data packet, into a 
24 holds the actual data being transmitted. Trailer 26 con- 3Q format for compatible transmission over a satellite or other 
tains forward error correction (FEC) information to help network system without losing the identify of the IP data 
verify whether the packets are transmitted error free. packet. In this manner, the network data packet can be used 
The data contained in each digital satellite packet resides by the computer application through a standard set of 
in the 127-byte payload 24. One common use of DSS existing APIs, rather than through proprietary or non- 
packets is to carry video and audio signals, such as those 35 standard functions known only to single monolithic client 
used in satellite-based television. Video and audio signals applications. 

require continuous streaming of data at a particular rate to CITm . ADV OT7 1KT , /cxrrrr , XT 

produce an even, uninterrupted presentation of images and SUMMARY OF THE INVENTION 

sounds. To convert the continuous data stream into indi- One aspect of this invention concerns a method for 

vidual packets, the data stream is broken into equal-size 40 encoding network data, such as Internet Protocol (IP) data, 

blocks of 127 bytes. Each block is inserted into a payload 24 into a format for transmission over a satellite system. The 

of a DSS packet 20. The individual packets are then trans- network data is configured in a packet having a data block 

mitted over the satellite system to a user's residence. The and header information. As an example, an IP packet has a 

data segments are extracted from the DSS packets and used variable-length data block consisting of the IP data and a 

to reconstruct the continuous data stream. These steps of 4S fixed -length header containing the IP header and a UDP 

packeting, transmitting, receiving, and reconstructing are (User Datagram Protocol) header. 

carried out at a sufficiently high rate to enable the video/ According to the method, the network data packet is 

audio signals to be played in real time at the receiver's encoded into a variable-length multi-packet transport (MPT) 

residence. frame. The MPT frame comprises a data frame and header 

Within the networking community, data is likewise car- 50 information. The IP packet is inserted in its entirety into the 

ried over data networks such as LANs (local area networks) data frame of the MPT frame. 

and WANs (wide area networks) in discrete digital packets. The variable-length MTP frame is then encoded into one 

One common and widely used type of network data is called D r more fixed-length MTP packets. Each MPT packet has a 

Internet Protocol (IP) data. IP data defines a standard format data fragment block comprising a portion of the MTP frame 

for carrying data over essentially any underlying network, 55 and associated header information to designate what portion 

including the Ethernet and the Internet. The IP standard 0 f the MTP frame is contained in the data fragment block, 

defines a packet used to encapsulate the data. The IP data is i n one implementation, the MPT packet header is a one-byte 

always encapsulated in this packet, regardless of the trans- header which includes a start-of-frame bit and an end-of- 

mission network, enabling it to be carried over many dif- frame bit. These two bits designate whether the data con- 

ferent networks. ( 60 tained in the associated data fragment block of the MTP 

Conventional network data is typically encapsulated in packet is the starting portion of the MPT frame, the ending 

packets that are much larger than 127 bytes. This presents a portion of the MPT frame, or a middle portion of the MPT 

problem for satellite transmission because the size of a frame. More particularly, the start-of-frame bit is set if the 

network data packet exceeds the payload size of a satellite data fragment block contains the starting portion of the MTP 

packet, such as the 127-byte payload of DSS packet 20. 65 frame. The end-of- frame bit is set if the data fragment block 

Moreover, the size of the network data packet can vary contains the ending portion of the MTP frame. Both bits are 

dramatically. Hence, defining a formula for converting one reset if the associated data fragment block contains the 
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middle portion of the MPT frame. In this manner, the header network 38. The satellite network 38 includes a satellite 

information helps re -assembly of the data fragments into the transmitter 40 located at the content provider 32. The 

MPT frame. satellite transmitter 40 transmits signals in the form of 

The MPT packets are a size appropriate for transmission individual digital packets to an orbiting satellite 42, which 
over the satellite system. In one implementation, the MPT 5 retransmits the digital packets back to a satellite receiver 44 
packets are sized to 127 bytes. At this size, the entire MPT located at the receiver's residence. One example of a suit- 
packet is embedded into the 127-byte payload of a conven- able satellite network 38 is a digital satellite system (DSS) 
tional 147-byte DSS packet network which transmits video and audio signals from a 

Using this method, data received over a data network (i.e., content provider to individual satellite receivers located at 

Ethernet or Internet) in large network data packets are 10 subscriber homes. In a DSS network, the satellite receiver 44 

broken into smaller packets denned by the multi-packet / srnall, 18-mch dish Uiat * capable of rece.ving the 

transport. These packets are then placed as the data payload s^te-transmuted signals. Tine DSS network supports 

within standard, fixed-size packets suitable for transmission feline-broadcast telev.s.on shows, movies, games, and the 

across a particular distribution medium, such as the DSS 1 e " 

network. The network data remains independent of the 15 More generally, the satellite signals can contain many 

underlying network and can be easily extracted at the different data types, including video, audio, animation, 

receiver for use by computer applications. textual, and the like. In the illustrated implementation, the 

According to another aspect, a method for decoding s f 1Ute s j?" als arc satellite receiver 44 to one 

computer network data from a satellite transmission signal is 9n of < wo d ^ c ™ 1 ^ of 6 ^ ™* * the receiver 

described. The satellite packets are received at a user-based 20 resid f " ce 34 " °f d ^ 15 ^bodied as a broadcas 

receiving unit. The data payloads are removed from the ™ M f Pf sona I^ om n pu ! er S \ m Sim ?X broadcast PC. 

satellite packets. Each data payload has the fixed-length ^ broadcast ?? 5 ° has \ lar § e VG U A f momto / 52 ' a 

multi-packet transport (MPT) packet, which comprises the Processing unit 54, and input devices m the form of remote 

data fragment block and associated header information. The „ ke ^ oard * and J" c ° ntro1 handse 58 * ™^ m <f 

decoding unit uses the header information of the MPT 25 ke y board 56 and handset 58 are remotely coupled to the 

packet to arrange the MPT packets into a variable-length ^ SSl ^ ™' * 4 ™ a wirclc8 ! data ^ SUC , h 88 mfrared 

MPT frame. The MPT frame is then reconstructed from the < IR > °' radl ° < RF >- 0t x her of m P ut de j vic f ( c * - ™ ouse ' 

data fragment blocks of the MPT packets and the network track ball, stylus, ete.) can be used instead of, or m addmon 

data is extracted from the reconstructed MPT frame. 3Q t0 ' the ke y board and handset - 

In this manner, network data is transmitted using conven- ^ ° ther dis P la y ™* / S ^ mbodied f a set - to P box 6 ° 

tional satellite packets without losing its known format. A coupled <° a conventional te evision 62 A remote control 

computer application at the user-based receiving unit can handset 64 I s ^ to IC ™ ^ ? n *° l t^ set-top box and 

use standard APIs, such as those prescribed by the Windows ^ le ^ 10Q ™* ™^ ss data h f* * another embodiment 

Sockets Specification, to call and access the network data. 35 the ^7^? in < he box 60 can be "^orated 

By encapsulating whole IP network data within satellite mt0 tne television 62. 

packets, content distributors will enable a wide new range of Content provider 32 is configured to package the signals 

applications. Applications developers will find it easy to in fixed-size digital packets. As an example, a DSS packet 

make use of such data since they will be writing to a standard has a size of 147 0 ytes, ^ described in the Background of 

interface with which they are already familiar. 40 the Invention section with respect to FIG. 1. The content 

provider 32 includes a encoding unit for encoding network 

BRIEF DESCRIPTION OF THE DRAWINGS data packets into a format for transmission over the satellite 

system 38. In the illustrated implementation, the encoding 

FIG. 1 is a diagrammatic illustration of a prior art digital unit at the content provider includes a multi-packet transport 

satellite system (DSS) packet structure. ( MP X) encoder 70 coupled to a data network 72, such as an 

FIG. 2 is a diagrammatic illustration of a satellite trans- Ethernet or the Internet. The MPT encoder 70 receives 

mission system. network data packets (e.g., TCP/IP packets or UDP/IP 

FIG. 3 is a flow diagram of a method for sending network packets) from the data network 72, wraps them in an MPT 

data over the satellite transmission system. frame format, and then splits the MPT frame into MPT 

HO. 4 is a diagrammatic illustration of a multi-packet 50 P ackets tha ! are suitably sized for satellite transmission. As 

transport (MPT) structure used to carry network data. one sample, »e MPT encoder can be implemented as a 

_„ .... • .„ • , wn-r. 1 . network router. The MPT frame and packet structures are 

k^ / 8 : ^ amm ? ,,c , ^"Strauon of an MPT packet describedb ei 0 winni 0 tedetoa.TlieMPTpickete«pi 8 sed 

embedded within a satellite-transmissible DSS packet. , . „. t WTTV/ ... , x . . c - A . 4i f 

v to a satellite MUX (multiplexor) interface 74 where they are 

FIG. 6 is a diagrammatic illustration of various packet encoded into satellite-transmissible packets. The satellite 

structures showing re-assembly of the network packets from 55 pac kets are then uplinked to the satellite transmitter 40. 

the MPT packets. FIG. 3 shows a method for operating the satellite trans- 

FIG. 7 is a block diagram of a satellite receiver/viewing mission system 30 to carry network data as part of the 

unit interface which shows data flow of network packets to satellite transmission. This method will be described with 

applications running at the viewing unit. reference to FIGS. 2 and 4-7. 

ou 

nFTAii Pn nFSrRTPTlON OF THF At step 100 > the MPT encoder 70 receives a network data 

PREFER^^ Packel fTOm the data netWOrk 72 - M aD eXam P le ' lhe 

PREFERRED EMBODIMENT Qetwork daU packet fe ^ tfae form of an {q[qtqg[ Protocol 

FIG. 2 shows a satellite transmission system 30 for (IP) packet, although other forms of packets may be used, 

delivering signals from a content provider 32 (e.g., cable 65 FIG. 4 shows an IP packet 120. It has a variable-length 

headend, television broadcast station, Internet service (N-byte) data payload 122, a fixed-length (A-byte) transport 

provider, etc.) to a receiver residence 34 over a satellite protocol header 124, and a fixed-length (B-byte) IP header 
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126. The data payload 122 contains the actual network data. 
The transport protocol header 124 designates the transport 
layer protocols for the data network. Examples of the 
transport protocol include Transmission Control Protocol 
(TCP) and User Datagram Protocol (UDP). In FIG. 4, the IP 
packet 120 has a UDP header 124 that is eight bytes in 
length. The IP header 126 provides the addressing informa- 
tion necessary to deliver the data from source to destination. 
In this example, the IP header 126 is 20 bytes in length. 

At step 102 in FIG. 3, the MPT encoder 70 encodes the 
network data packet into a variable-length MPT frame 130. 
The MPT frame 130 has a variable-length (M-byte) data 
block or data payload 132 and a fixed-length (C-byte) type 
header 134. The IP packet 120 is inserted in its entirety 
(including both headers) into the data payload 132 of the 15 
MPT frame. As an example implementation, the header 134 
contains a two-byte protocol identifier, which for IP data, has 
a value of 0x0800. The header 134 might also contain 
optional bytes for designating protocol options. 

The MPT frame 130 might also have a trailer 136 attached 
to the data payload 132. The trailer 136 includes one or more 
optional padding bytes 136 which bring the total number of 
bytes for the last portion of the MPT frame 130 to a size 
suitable for insertion into a fixed-size MPT packet, as is be 
described below in more detail. The trailer 136 might also 
designate space for further use, as well as length data that 
specifies the length of the actual data frame 132 and the 
optional bytes for protocol options. 

At step 104 of FIG. 3 the MPT encoder 70 encodes the 
variable-length MVT frame 130 into one or more fixed- 
length MPT packets 140(1), 140(2), . . . , 140(n). In the 
illustrated implementation, each MPT packet 140 consists of 
127 bytes. Each MPT packet has 140 a data block 142, 
which can vary in size depending upon the packet contents, 
and at least a flag header 144. 

During encoding, the MPT frame 130 is broken into data 
fragments which form the data fragment blocks 142(1), 
142(2), . . . , 142(n) of the MPT packets 140(1), 140(2), . . 
. , 140(n). The flag headers 144(1), 144(2), . . . , 144(n) are 
then attached to the front of the corresponding the data 
fragment blocks 142(1), 142(2), . . . , 142(n). In the 
illustrated implementation, each flag header 144 has a size 
of one byte. The flag header 144 contains two flag bits 146, 
four undefined bits 148, one start-of-frame (SOF) bit 150, 
and one end-of-frame (EOF) bit 152. The SOF bit and EOF 
bit are the least significant bits of the flag header. 

The SOF and EOF bits 150 and 152 designate whether the 
data fragment from the MPT frame that is contained within 
the corresponding data block 142 is a starting portion of the 
MPT frame, an ending portion of the MPT frame, or a 
middle portion of the MPT frame. More particularly, SOF bit 
150 is set if the corresponding data fragment 142 is from the 
starting portion of the MTP frame 130. The EOF bit 152 is 
set if the data fragment 142 is from the ending portion of the 55 
MTP frame 130. Both the SOF and EOF bits are reset if the 
data fragment is from the middle portion of the MPT frame 
130. 

In FIG. 4, MPT packet 140(1) is an example leading 
packet containing the starting data fragment of the MPT 60 
frame 130. Accordingly, the SOF bit is set to binary "1" and 
the EOF is reset to binary "0" as represented by box 154. 
The last MPT packet 140(n) is an example ending packet 
which contains the ending data fragment of the MPT frame 
130. As a result, the SOF bit is reset to binary "0" and the 
EOF is set to binary "1" as represented by box 156. MPT 
packet 140(2) is an example middle packet which contains 



a middle data fragment of the MPT frame 130, and hence, 
both the SOF and EOF bits are reset to binary "0" as 
represented by box 158. 

The leading MPT packet 140(1) has an address header 
160 positioned before the data block 142(1). In the example 
implementation, the address header 160 consists of a six- 
byte value. This is used in combination with the existing 
service channel identification number (SCID), and is known 
as a "sub-SCID." As a result, the leading MPT packet 140(1) 
comprises a one-byte flag header 144(1), a six-byte address 
header 160, and a 120-byte data block 142(1). 

The last MPT packet 140(n) has an error correction trailer 
162 containing error correction data positioned after the data 
block 142(n). As an example, the error correction trailer 162 
contains a 32-bit CRC (cyclic redundancy check) value that 
is computed for all preceding MPT packets 140(l)-140(n), 
which is represented as the bytes within dashed box 164. 
CRC error checking is a procedure used to check for errors 
in data transmission. It involves a complex calculation to 
generate a value based upon the data being transmitted. A 
CRC value is computed at the transmitter and attached as 
part of the transmitted packet. The receiver repeats the 
calculation and compares it to the attached CRC value. If the 
receiver's calculation and the attached CRC value match, the 
transmission of data is assumed to be error-free. CRC is well 
known and widely used. It is noted that other types of error 
correction values can be alternatively employed. 

The last MPT packet 140(n) thus comprises a one-byte 
flag header 144(n), a 122-byte data block 142(n), and a 
flour-byte error correction trailer 162. All middle MPT 
packets 140(2), . . . , 140(n-l) comprise a one-byte flag 
header 144 and a 126-byte data block 142. 



35 
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Table 1 summarizes foui possible packet types depending upon the 
values of the SOF and EOF bits of the flag byte header 

SOF EOF Description 

1 0 The first packet of a multi-packet MPT 

frame. The six bytes following the flag 
header are the sub-SCID address, followed 
by 120 bytes of fragment data. 
The CRC is accumulated on all bytes of 
this packet. 

0 0 An intermediate (neither the first, nor last) 

packet of a multi-packet MPT frame. 126 
bytes following the flag byte are fragment 
data. 

The error correction information is 
accumulated on all bytes of this packet. 

0 1 The last packet of a multi-packet MPT 

frame. The flag header is followed by 122 
bytes of data and 4 bytes of error correction 
information. 

The error correction information is 
accumulated on the first 123 bytes of this 
packet. 

1 1 The first, last, and only packet of a single- 

packet MPT frame. The six bytes following 
the flag header are the sub-SCID address, 
followed by 116 bytes of data, followed by 
four bytes of error correction information. 
The error correction information is 
accumulated on the first 123 bytes of this 
packet 



At step 106 of FIG. 3, the satellite MUX interface 74 
embeds the MPT packets 140 into fixed-length satellite 
packets for transmission over the satellite network 38. For 
purposes of continuing discussion, this step is described in 
the context of DSS data packets, which have a fixed length 
of 147 bytes. 
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FIG. 5 shows an MPT packet 140 and its relationship to 
a 147-byte DSS packet 20, which is the same packet as 
described with respect to FIG. 1. In this implementation, the 
first two flag bits 146 of flag header 144 are set to zero to 
represent a DSS packet format. The entire 127-byte MPT 5 
packet 140 is inserted into the 127-byte data payload 24 of 
the conventional DSS packet 20. A three-byte DSS header 
22 is attached to the front of the data payload 24. The header 
22 contains four flag bits, twelve addressing bits for the 
service channel identification number (SCID), four sequence 
bits, and four type bits. A 17-byte trailer 26 is attached to the 
end of the data payload 24 and contains forward error 
correction (FEC) information computed according to con- 
ventional techniques. 

It is noted that the MPT encoder 70 can be implemented 
in hardware, software, or a combination hardware/software. 15 
In hardware, the network data packet received from the data 
network 72 is initially placed in a register. A header 134 and 
optional padding 136 are added to form the MPT frame 130, 
which is stored in another register. The MPT frame 130 is 
then passed to a shift register in the MPT encoder 70. The 20 
first 120 bytes are shifted out and a one-byte flag header 144 
and six-byte address header 160 are added thereto to form a 
leading MPT packet 140(1). The leading MPT packet 140(1) 
is stored in a separate register. Thereafter, the MPT frame 
130 is shifted out 126 bytes at a time, with a flag header 144 25 
being added to each, to form the middle MPT packets 
140(2), . . . , 140(n-l). When the end of the MPT frame 130 
is reached, the last data bytes are shifted out and a one-byte 
flag header 144(n) is added to form the last MPT packet 
140(n). A CRC value is then computed using all MPT 30 
packets stored in the various registers. The CRC value is 
attached as a four-byte trailer 162 to the last MPT packet 
140(n). 

In a software implementation, the network data packet is 
cached in memory. The MPT frame header and padding are 35 
wrapped around the network data packet. The software then 
segments the MPT frame into appropriately sized data 
fragments and adds the flag header. The address header is 
added to the first MPT packet. The software then computes 
a CRC value and attaches it as a trailer to the last MPT 40 
packet. 

At step 108 in FIG. 3, the satellite packets are transmitted 
from the content provider 32 over the satellite network 38 to 
the receiver residence 34. The DSS packets are transmitted 
on multiple SCIDs and the satellite receiver 44 supports 45 
reception on the multiple SCIDs simultaneously. The satel- 
lite receiver 44 supports wideband packet synchronization 
(i.e., a technique for processing data received from the 
satellite network) to discover boundaries of the DSS pack- 
ets. 50 

As the satellite receiver 44 receives the satellite packets 
(step 110 in FIG. 3), it uses the last 17 bytes to perform an 



of the 147-byte DSS packet. Unwanted packets are dis- 
carded. The acceptable packets are passed to a decoding unit 
which is implemented as part of the satellite receiver, and 
preferably in software. 

FIG. 6 shows the intermediate data structures during 
re-assembly of the network data packet within the satellite 
receiver, and its conversion into a packet which conforms to 
the Ethernet Protocol. The satellite receiver 44 first strips the 
17-byte FEC trailer from the satellite packet to extract the 
MPT packet (step 112 in FIG. 3). The three-byte DSS packet 
header 22 may or may not remain as part of the extracted 
MPT packet 140'. After the SCID address is used to initially 
group and filter the DSS packets, the information contained 
in the three-byte DSS packet header becomes irrelevant and 
can therefore be dropped. 

The MPT packet 140' has intact the flag header 144 (and 
address header for the first packet), as well as the fragment 
data in the data block 142. The satellite receiver fillers 
unwanted MPT packets using the sub-SCID addresses con- 
tained in the leading MPT packet. The sub-SCID addresses 
are 48 bits long, and are positioned as the fourth through 
ninth bytes in the MPT packet. The sub-SCID addresses are 
synchronized across the SCIDs used to transmit the MPT 
packets, but filtering on the sub-SCID addresses is per- 
formed without regard to the SCID for the satellite packet. 

In an example embodiment, the satellite receiver filters on 
at least 16 different sub-SCIDs simultaneously. Unwanted 
MPT packets are discarded, while the MPT packets with the 
appropriate sub-SCID addresses are kept. It is desirable to 
filter on as many sub-SCIDs as possible. Many broadcast 
data satellite systems are capable of filtering on 32 different 
sub-SCIDs. Additionally, the satellite receiver should also 
support a "promiscuous" mode, in which it does not filter 
any sub-SCIDs; rather packets from all selected SCIDs pass 
through. For efficiency and throughput, the sub-SCID 
addresses are capable of being loaded within 10 ms and 
being disabled and enabled with a single operation. 

At step 114 in FIG. 3, the decoding unit at the satellite 
receiver reconstructs the MPT frame 130' from multiple 
MPT packets 140* (FIG. 6). The flag header of each MPT 
packet is read to determine whether it is the lead MPT packet 
(e.g., SOF-1, EOF«0), a middle MPT packet (e.g., SOF-0, 
EOF=0), or the last packet (e.g., SOF=0, EOF-1). 

The following is an example of an IP data packet being 
carried by MPT packets to illustrate byte order and outputs. 
In the examples below, data is represented exactly as it 
arrives from the satellite network, as well as how it is stored 
in memory, byte per byte. Example 1 is for a single packet 
MPT frame. 
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FEC (forward error correction) analysis to ensure that the 65 

DSS packet is intact. The satellite receiver 44 then filters the The first byte "3F" is the flag header, and the "F" value 
DSS packets using the SCID address in the first three bytes indicates that both the SOF and EOF bits are set to "1". 
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Accordingly, the MPT packet has both an address header and the least significant byte of the CRC is contained in the 

and a CRC trailer. last byte of the CRC trailer 162 (i.e., the 130* byte of the 

Example 2 is for a mult-packet MPT frame. In this DSS packet). A match of the CRC computed by the satellite 
example, the MPT frame contains two packet. 
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The flag header in the first packet is "3E" which indicates 
that the least significant bit (i.e., the EOF bit) is a "(T and 25 
the next least significant bit (i.e., the SOF bit) is a "1". Such 
EOF and SOF bit values indicate that the first packet is a lead 
MPT packet. The flag header of "3D" in the second packet 
establishes a SOF«0 and EOF-1, indicating that the second 
packet is a last MPT packet. 3Q 

As the MPT packets are being arranged beginning with 
the lead MPT packet, the satellite receiver begins compiling 
a CRC value. Multi-Packet CRCs are used to detect dropped 
packets, as well as packets that make it through the FEC 
analysis yet contain undetected errors. Under most 35 
circumstances, packets arriving from the satellite network 
with errors are detected by the FEC analysis, and appropriate 
action is taken. In some circumstances, however, packets 
arrive containing too many errors for the FEC to correct, and 
the errors occur in such a way that the FEC mistakenly 43 
reports that all errors have been corrected. This occurrence 
happens at a rate of 1/N! where N is the number of bytes that 
can be corrected. For the DSS system, the probability of not 
delecting that condition and falsely reporting a valid packet 
are 2.48E-5. A much lower error rate of under 2.07E-17 is 45 
desired. The 32-bit CRC value provided for each MPT frame 
is suitable for signal conditions at "video threshold," and 
will achieve the strict error rate. 

The satellite receiver accumulates the CRC across mul- 
tiple packets. The CRC calculation is independent of sub- 50 
SCID filtering. The last MPT packet is reached when the 
EOF in the flag header is set to "1". The CRC is accumulated 
for all bytes in the MPT frame 130', excluding the 4-byte 
trailer 162 containing the CRC value. The CRC value 
thereby includes flag headers, data fragments, and the 6-byte 55 
sub-SCID address of the first MPT packet. This corresponds 
to the fourth through 130** bytes of each DSS packet (except 
the one containing the last MPT packet) received at the 
satellite receiver. The CRC is accumulated in order, byte per 
byte, from each DSS packet. 60 

When the EOF condition is detected, the calculated CRC 
value is compared to the CRC value attached as trailer 162 
in the last MPT packet. As an example, the CRC value in the 
MPT packet is stored in the Network Byte Order format, 
which is also called "Big Endian." This means that the most 65 
significant byte of the CRC is contained in the first byte of 
the CRC trailer 162 (i.e., the 127 th byte of the DSS packet) 



receiver and the CRC attached as the four-byte trailer 162 in 
the last MPT packet evidences an error-free transmission. 

In one implementation, the satellite receiver may support 
only one CRC accumulator to compute the CRC value. MPT 
packets belonging to different MPT frames (and hence 
having differing sub-SCIDs) are not interleaved. Packets for 
the next MPT frame are taken after the last MPT packet for 
the previous MPT frame is reached. On the other hand, in 
another implementation where the satellite receiver supports 
MPT packet reception on multiple SCIDs, each SCID might 
have a corresponding CRC accumulator, one for each MPT 
packet in the process of being received. Multiple CRC 
accumulators are useful as there may not be any way to 
synchronize starting and stopping multiple MPT frames 
between SCIDs. 

As an example implementation, the CRC algorithm used 
by a DSS -compatible satellite receiver is the same CRC 
algorithm as used by the MPEG-2 Transport stream as 
defined in the standard ISO/IEC 13818-1. The algorithm 
consists of the polynomial: 

l+D+D 2 +D 4 +D 5 +D 7 +D B +D 10 +D 11 +D 12 +D 1(I +D 22 +D 23 +D 2<I +D 32 

As in the ISO/IEC 13818-1 specification, the initial state 
of the sum is OxFFFFFFFF. This is not the same algorithm 
used by Ethernet. 

In the above discussion, the CRC calculation is performed 
by the satellite receiver. Alternatively, the CRC calculation 
can be computed by a processor in the visual display units. 
This is described below in more detail. Performing the CRC 
calculations using the processor, however, consumes a high 
amount of the available computational resources. 
Accordingly, it is preferred that the CRC be performed by 
the satellite receiver. 

If the CRC analysis is favorable, the next step 116 of FIG. 
3 is to extract the network data packet 120' from the MPT 
frame 130 f . In the continuing example, the IP packet 120' has 
intact the N-byte data payload 122, the 8-byte UDP header 
124, and the 20-byte IP header 126. To ensure that the IP 
packet 120' conforms to the Ethernet Protocol, the sub-SCID 
address header 160 found in the first MPT packet 140(1) is 
placed in the beginning of the IP packet as a network 
destination address 170 (e.g., an Ethernet Destination 
address). A network source address 172 is filled with a fixed, 
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valid source address (e.g., an Ethernet Source address). A 
two-byte protocol 174 is filled with the protocol from header 
134 of the MPT packet 130', without modification. Any 
protocol options from header 134 is appended to the IP 
packet 120' as well as all subsequent MPT packets until an 
EOF condition is met. 

Once the EOF condition is met, the CRC is checked as 
described above, and if the comparison was successful, the 
true length of the data is recorded, the simulated IP packet 
is written to the memory of the visual display unit, and the 
visual display unit is notified that an IP packet has arrived. 

An alternate method would be when the network data 
packets are reassembled within the processor of the visual 
display unit. The MPT packets are written into main 
memory in the order in which they arrive. The entire MPT 
packet 140* is written to memory. In order to enhance 
performance, rather than writing out a packet stream of 127 
byte MPT packets, the packets are aligned on 128-byte 
blocks. The first byte is written in the form of padding or 
internal flags, which can be used by the satellite receiver 
card for whatever internal purpose. For purposes of network 
data reconstruction, however, this first byte is considered as 
"don't care." The remaining 127 bytes include the flag and 
address headers 144, 160 (if a first packet; otherwise just the 
one-byte flag header), and a data block 142 holding the data 
fragment. Memory buffers are preferably configured in 
multiples of 128 bytes. MPT Packets are written to align on 
four-byte double word or "DWORD" boundaries. By writ- 
ing the MPT packets in this way, and by aligning bytes on 
predicable DWORD boundaries, software running on com- 
mon processors can be optimized to a higher degree than 
would be possible by not aligning the data. 

Even in the case where the visual display unit performs 
re-assembly, it is preferred that the satellite receiver perform 
the CRC calculations. This is desired due to the computa- 
tional burden of requiring the video display unit to perform 
these calculations. The video display unit is needed to 
perform time critical user interface tasks as well as other 
data processing tasks and any unnecessary burden is noticed. 

The satellite receiver determines whether the CRC failed 
by including the CRC bytes in the CRC calculations and 
writing the result in place of the original CRC bytes. If the 
CRC value that was calculated over the original data is fed 
through the CRC algorithm as an additional four bytes, the 
new CRC result will have the value of zero upon success, 
and non-zero upon failure. 

The video display unit then performs the same operations 
as the satellite receiver in order to create an packet that 
conforms to the IP packet. 

FIG. 7 shows the interface between the satellite receiver 
and decoding unit and a software application running on the 
computer at the visual display unit. A satellite receiver board 
200 places the recovered network data packets onto the PC 
bus 202. A miniport driver 204 and layered miniport driver 
206 are coupled to receive the packets from the PC bus 202. 
In the illustrated example, the drivers comply with the 
Network Device Interface Specification (NDIS) 4.0, as 
represented by interface layer 208. 

The reassembled network data packet is passed to the IP 
software interface 210 which performs some rudimentary 
error checking at the network data packet level (e.g., header 
checksum) and filtering. At this point, the network data 
packet is in order to be handled by the Winsock layer 212, 
a software implemented interface which complies with the 
Windows Sockets Specification. The Windows Sockets 
Specification defines a well known standard set of APIs that 
provide a network independent way to send and receive data. 
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An application 214 uses the network data packets through 
various API calls orchestrated through the Winsock layer 
212. 

This invention is beneficial in that it prescribes a tech- 
nique for transmitting network data over a satellite system 
without losing its known format. A computer application at 
the recipient can use standard APIs, such as those prescribed 
by the Windows Sockets Specification, to access and utilize 
the network data. 

It is noted that aspects of this invention can be used for 
network types other than satellite networks. The MPT frame 
and MPT packet structure can be modified for use with other 
networks, including Ethernet and Internet. 

In compliance with the statute, the invention has been 
described in language more or less specific as to structural 
and methodical features. It is to be understood, however, that 
the invention is not limited to the specific features described, 
since the means herein disclosed comprise preferred forms 
of putting the invention into effect. The invention is, 
therefore, claimed in any of its forms or modifications within 
the proper scope of the appended claims appropriately 
interpreted in accordance with the doctrine of equivalents. 

What is claimed is: 

1. A method for encoding internet protocol (IP) data into 
a format for transmission over a satellite system, comprising 
the following steps: 

receiving an IP packet having an IP data block and header 
information; 

encoding the IP packet into a variable-length multi-packet 
transport (MPT) frame having a data frame and header 
information so that the data frame of the MPT frame 
comprises the IP packet; and 

encoding the variable-length MPT frame into a plurality 
of fixed-length MPT packets, each MPT packet having 
a data fragment block comprising at least a portion of 
the MPT frame and associated header information to 
designate what portion of the MPT frame is contained 
in the data fragment block, and wherein one of the 
plurality of MPT packets includes frame error correc- 
tion information associated with the entire data frame 
within the variable-length MPT frame. 

2. A method as recited in claim 1, wherein the header 
information of each MPT packet designates whether the data 
contained in the associated data fragment block is from a 
starting portion of the MPT frame, an ending portion of the 
MPT frame, or a middle portion of the MPT frame. 

3. A method as recited in claim 2, wherein the header 
information of each MPT packet comprises a one-byte 
header having a start-of-frame bit which is set if the data 
contained in the associated data fragment block of the MPT 
packet comprises the starting portion of the MPT frame and 
an end-of-frame bit which is set if the data contained in the 
associated data fragment block of the MPT packet comprises 
the ending portion of the MPT frame, the start-of-frame and 
end-of-frame bits both being reset if the data contained in the 
associated data fragment block of the MPT packet comprises 
the middle portion of the MPT frame. 

4. A method as recited in claim 2, wherein the header 
information of each MPT packet comprises a multi-byte 
address in an event that the data contained in the associated 
data fragment block is the starting portion of the MPT frame. 

5. A method as recited in claim 1, further comprising the 
step of calculating the frame error correction information for 
the entire data frame within the variable-length MPT frame. 

6. A method as recited in claim 5, further comprising the 
step of attaching the frame error correction information to 
only one of the MPT packets. 
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7. A method as recited in claim 1, further comprising the 
step of adding a header including an address and a trailer 
with MPT packet error correction information to each fixed- 
length MPT packet to form satellite-transmittable packets. 

8. A method as recited in claim 7, further comprising the 5 
step of transmitting the satellite-transmittable packets. 

9. A method for encoding internet protocol (IP) data into 
a format for transmission over a satellite system, comprising 
the following steps: 

receiving an IP packet having an IP data block, a transport 1Q 
protocol header, and an IP header; 

constructing a variable-length multi-packet transport 
(MFI*) frame having a data payload and a header; 

inserting the entire IP packet into the data payload of the 
MPT frame; and 

constructing from the MPT frame a plurality of fixed-size 
multi-byte MPT packets, each MPT packet having at 
least one header to designate what portion of the MPT 
frame is contained in the MPT packet, and wherein one 
of the plurality of MPT packets includes frame error 20 
correction information associated with the entire data 
payload within the variable-length MPT frame. 

10. A method as recited in claim 9, further comprising the 
step of calculating the frame error correction information for 
the plurality of MPT packets. 25 

U. A method as recited in claim 10, further comprising 
the step of attaching the frame error correction information 
as a multi-byte trailer to only one of the MPT packets. 

12. A method as recited in claim 9, further comprising the 
step of transmitting the MPT packets. 30 

13. A method for encoding network data packets into a 
format for transmission over a distribution system, the 
method comprising: 

adding a header to a network data packet to form a 
variable-length multi-packet transport (MPT) frame; 35 

segmenting the MPT frame into a plurality of data frag- 
ment blocks; and 

adding a header to each data fragment block to form 
fixed-length MPT packets of a size appropriate for 
transmission over the distribution system, and wherein 40 
one of the plurality of MPT packets includes frame 
error correction information associated with the entire 
network data packet within the variable-length MPT 
frame. 

14. A method as recited in claim 13, wherein the header 45 
of each MPT packet designates whether the data contained 

in an associated data fragment block is from a starting 
portion of the MPT frame, an ending portion of the MPT 
frame, or a middle portion of the MPT frame. 

15. A method as recited in claim 13, wherein the header 50 
of each MPT packet comprises a one-byte header having a 
start-of-frame bit which is set if the data contained in the 
associated data fragment block of the MPT packet comprises 
the starting portion of the MPT frame and an end-of-frame 
bit which is set if the data contained in the associated data 55 
fragment block of the MPT packet comprises the ending 
portion of the MPT frame, the start-of-frame and end-of- 
frame bits both being reset if the data contained in the 
associated data fragment block of the MPT packet comprises 
the middle portion of the MPT frame. 60 

16. A method as recited in claim 13, further comprising 
the step of adding padding bits as a trailer to the network 
data packet to form the MPT frame. 

17. A method as recited in claim 13, wherein the step of 
adding a header comprises the step of adding a header which 65 
designates what portion of the MPT frame is contained in the 
data fragment block. 
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18. A method as recited in claim 13, further comprising 
the step of adding an address to a first data fragment block. 

19. A method as recited in claim 13, further comprising 
the step of calculating error correction information for the 
MPT packets, 

20. A method as recited in claim 19, further comprising 
the step of attaching the error correction information to one 
of the MPT packets. 

21. A method as recited in claim 13, further comprising 
the step of adding a header including an address and a trailer 
with error correction information to each fixed-length MPT 
packet to form satellite-transmittable packets. 

22. A method as recited in claim 21, further comprising 
the step of transmitting the satellite-transmittable packets 
over a satellite distribution system. 

23. A method for decoding computer network data from 
a satellite transmission signal, comprising the following 
steps: 

receiving a plurality of satellite packets, each satellite 
packet having a data payload; 

removing the data payloads from each of the satellite 
packets, each data payload comprising a fixed-length 
multi-packet transport (MPT) packet having a data 
fragment block and associated header information; 

using the header information of the MPT packet to 
arrange the MPT packets into a variable-length MPT 
frame; 

reconstructing the MPT frame from the data fragment 

blocks of the MPT packets; and 
extracting the network data from the reconstructed MPT 

frame, and 

wherein, one of the plurality of MPT packets includes 
frame error correction information associated with the 
network data within the variable-length MPT frame. 

24. A satellite transmission system, comprising: 

an encoding unit to encode a network data packet into a 
plurality of satellite packets, the encoding unit being 
configured to (1) add a header to the network data 
packet to form a variable-length multi-packet transport 
(MPT) frame, (2) segment the MPT frame into a 
plurality of data fragment blocks, (3) add a header to 
each data fragment block to form fixed-length MPT 
packets, (4) add header/trailer information to each MPT 
packet to form one or more satellite packets, and (5) 
include frame error correction information associated 
with an entire network data packet within one of the 
data fragment blocks; 

a satellite transmission unit coupled to receive the satellite 
packets from the encoding unit, the satellite transmis- 
sion unit transmitting the satellite packets over a sat- 
ellite network; 

a receiving unit to receive the satellite packets from the 
satellite network; and 

a decoding unit coupled to the receiving unit to recover 
the MPT packets from the satellite packets, reconstruct 
the MPT frame from the MPT packets, and extract the 
network data packet from the MPT frame. 

25. An encoding unit for encoding network data packets 
into a format for transmission over a satellite system, 
comprising: 

means for adding a header to a network data packet to 
form a variable-length multi-packet transport (MPT) 
frame; 

means for segmenting the MPT frame into a plurality of 
data fragment blocks; 
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means for adding a header to each data fragment block to 
form fixed-length MPT packets of a size appropriate for 
transmission over the satellite system, and 

means for configuring one of the plurality of MPT packets 
to includes frame error correction information associ- 5 
ated with the entire network data packet within the 
variable-length MPT frame. 

26. An encoding unit as recited in claim 25, wherein the 
header for the MPT packets designates what portion of the 
MPT frame is contained in the data fragment block. 10 

27. An encoding unit as recited in claim 25, further 
comprising means for adding padding bits as a trailer to the 
network data packet to form the MPT frame. 

28. An encoding unit as recited in claim 25, further 
comprising means for adding an address to a first data 15 
fragment block. 

29. An encoding unit as recited in claim 25, further 
comprising means for calculating the frame error correction 
information and including the error correction information 

to one of the MPT packets. 20 

30. An encoding unit as recited in claim 25, further 
comprising means for adding a header including an address 
and a trailer with packet error correction information to each 
MPT packet to form satellite-transmittable packets. 

31. A receiving unit for decoding data, comprising: 25 
a receiver to receive multiple satellite packets, individual 

satellite packets having a data payload comprising a 
fixed-length multi-packet transport (MPT) packet, each 
MPT packet having a data fragment block and associ- 
ated header information; 30 

a device driver coupled to the receiver; 

one of the receiver or device driver being configured to 
remove the MPT packets from the satellite packets and 
use the header information of the MPT packet to 35 
arrange the MPT packets into a variable-length MPT 
frame, said one of the receiver or device driver being 
further configured to reconstruct the MPT frame from 
the data fragment blocks of the MPT packets and 
extract the network data from the reconstructed MPT 40 
frame, and wherein one of the MPT packets includes 
frame error correction information associated with the 
entire network data within the variable-length MPT 
frame. 

32. A computer-readable medium comprising computer 45 
executable instructions for: 

converting a network data packet into a variable-length 

intermediate structure; 
segmenting the intermediate structure into a plurality of 

data fragment blocks; and 
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adding a header to each data fragment block to form 
fixed-length packets of a size appropriate for transmis- 
sion over the distribution system, and wherein only one 
of the plurality of data fragment blocks includes error 
correction information associated with the variable- 
length intermediate structure. 

33. A method for encoding network data packets into a 
format for transmission over a distribution system, compris- 
ing the following steps: 

expanding a network data packet into a variable-length 
intermediate structure; and 

converting the variable-length intermediate structure into 
a plurality of fixed-length packets of a size appropriate 
for transmission over the distribution system, and 
wherein only one of the fixed-length packets includes 
error correction information associated with the entire 
variable intermediate structure. 

34. A computer-readable medium comprising computer 
executable instructions for: 

expanding a network data packet into a variable-length 
intermediate structure; and 

converting the variable-length intermediate structure into 
a plurality of fixed-length packets of a size appropriate 
for transmission over the distribution system, and 
wherein only one of the fixed-length packets includes 
error correction information associated with the entire 
variable intermediate structure. 

35. A method for encoding internet protocol (IP) data into 
a format for transmission over a satellite system, comprising 
the following steps: 

receiving an IP packet having an IP data block, a transport 
protocol header, and an IP header; 

constructing a variable-length multi-packet transport 
(MPT) frame having a data payload, a header, and a 
trailer, the header containing a protocol identifier to 
identify the data as being IP data; 

inserting the entire IP packet into the data payload of the 
MPT frame; and 

constructing from the MPT frame a plurality of fixed -size 
MPT packets, each MPT packet having a first header 
containing a start of frame bit and an end of frame bit 
to designate what portion of the MPT frame is con- 
tained in the MPT packet and a second header contain- 
ing an address, and wherein one of the fixed-length 
packets includes error correction information associ- 
ated with the entire MPT frame. 
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